 |
||
|
||
ПОСТОБЪЕКТНЫЙ ПОДХОД К ПРЕДСТАВЛЕНИЮ ЗНАНИЯ
А.О. Поляков, В.И. Гришков
Санкт-Петербургский институт информатики и автоматизации РАН
Abstract — Numbers of researches have been made in order create database structure. The purpose of these researches was 'to keep more sense of the data" more or less formally. In this issue one variant of semantic model of knowledge named post-objected approach to presentation of knowledge is shown. First of all it is an uniform integrated approach of connection theory of sets with multi-dimension presentation of data. Some questions of post-object application of the approach to realization of selfstructured databases have been examined. Post-object approach of knowledge presentation is a really alternative predicate of knowledge presentation since the class can act both in a role of concept, and in role of the relation between concepts. The main property of this approach is it visual knowledge presentation.
В последнее время рядом исследователей изучались семантические модели для логического формирования баз данных. Цель заключалась в том, чтобы более или менее формальным образом “удерживать больше смысла данных”. Благодаря этому проектирование баз данных могло бы стать в большей мере семантическим, и сама система базы данных могла бы вести себя более разумным образом.
Здесь “семантическое” не должно интерпретироваться в каком-либо абсолютном смысле. Более того, ранее известные модели баз данных (“синтаксические”) содержали в себе и некоторые семантические возможности. Но цель является тем не менее чрезвычайно важной, ибо ведет к возможности отвечать на запросы и другие транзакции более осмысленным образом. Такая модель могла бы послужить также более эффективным посредником между многочисленными внешними представлениями, используемыми прикладными программами и конечными пользователями, с одной стороны, и многочисленными внутренне хранимыми представлениями, с другой стороны.
Рассмотрим вариант семантической модели знания, называемый постобъектным подходом к представлению знания, на основе программного продукта СУБД Cache фирмы Intersystems. Прежде всего это единый интегрированный подход, связывающий теорию множеств с многомерным представлением данных. Intersystems взяла на вооружение принцип “определи однажды - используй везде” в качестве подхода к управлению данными. В Cache каждый объект - таблица, а каждая таблица – объект (основная суть постобъектного подхода). Данные Cache автоматически доступны объектным языкам и SQL, без потребности в дополнительном “шлюзовании” и без дополнительного уровня “трансляции” между прикладной логикой и базой данных.
Семантическая модель представления знания описывается с помощью классов, которые могут порождать экземпляры классов (объекты). Cache полностью поддерживает объектную архитектуру, в частности, такие ее основы как множественное наследование, полиморфизм и коллекции. С этими возможностями разработчики могут моделировать предметную область (т.е. создавать семантическую сеть) реалистическими, понятными способами, таким образом ускоряя прикладную разработку. Класс в Cache – это формальное описание свойств и методов, присущих объекту. Объект – экземпляр класса. Объект представляет собой конкретное воплощение совокупности свойств и методов, определяемых классом. Таким образом класс тождественен декларативному описанию знаний, отвязанному от данных. Возможно создание класса, не предназначенного для порождения объектов.
На определенном этапе описания знаний приходится иметь дело с сущностями, которые в отличие от объектов могут иметь сразу несколько типов или различные типы по отношению к разным объектам или другим сущностям. Чтобы не было путаницы в терминологии – понятие ‘тип’ и ‘класс’ равнозначны в данном контексте. Выявление сущностей является следующим шагом представления знаний в Cache. Для описания сущности нужно создать новый класс который должен быть потомком тех классов, типы которых должна поддерживать эта сущность. Однако все унаследованные свойства нужно переопределить таким образом, чтобы они стали ссылками на соответствующие объекты. Так как поведение сущности описывает класс, а класс в Cache предназначен для порождения объектов, то сущность должна выступать в роли объекта, но это не совсем так. В
Cache используется особая идеология порождения и хранения объектов, не имеющая прямых аналогов в реляционных СУБД. В момент записи в базу данных объекту присваивается уникальный номер OID – идентификатор объекта, по которому его можно однозначно определить среди других объектов того же класса. Когда объект считывается в память, ему присваивается уникальный номер OREF – ссылка на объект, которая однозначно определяет объект в памяти программы. При окончании работы с объектом его состояние можно сохранить, а соответствующая конструкция уничтожается. Класс можно описать таким образом, что некоторые свойства объекта могут быть не определены (они физически могут не храниться ни в памяти, ни в БД), что важно для сущностей, так как сущность, порожденная конкретным классом, может иметь ссылки на объекты, а может их и не иметь (например поставщик может быть также покупателем, а может и не быть). Представляется очевидной необходимость уникальных и неизменных идентификаторов для сущностей БД. При необходимости, как и в реляционных СУБД, ключи (OREF и OID) могут нести семантическую нагрузку.Для того, чтобы более точно представить реализованный в Cache механизм отображения знаний на реляционные таблицы, созданный с помощью классов, нужно дать однозначное соответствие основных понятий реляционного исчисления с понятиями постобъектного подхода представления знаний.
Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres).
Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену.
Понятия домен и тип данных соответствуют понятию свойство в постобъектном подходе.
Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута). Схема БД (в структурном смысле) - это набор именованных схем отношений. Схеме отношения будет соответствовать следующая структура: в классе, принадлежащему базовой модели
Datatype, определяется домен , в классе, принадлежащему другой базовой модели, объявляется свойство тип которого совпадает с типом класса, в котором этот домен определен – именованное множество таких пар и есть схема отношения.Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. “Значение” является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или “арность” кортежа, т.е. число элементов в нем, совпадает с “арностью” соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа. Кортеж соответствует объекту (экземпляру класса), тем не менее сам кортеж в Cache может содержать неопределенные значения. Арность кортежа задает класс.
Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят “отношение-схема” и “отношение-экземпляр”, иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой. Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Во многих реализациях допускается изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных. Отношение соответствует множеству объектов принадлежащих одному классу, но возможны кортежи – дубликаты. В терминологии постобъектного подхода под термином эволюция схемы базы данных можно понимать изменение существующих и (или) создание новых классов.
То свойство, что отношения не должны содержать кортежей - дубликатов, следует из определения отношения как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов. В Cache объект имеет OREF (если он загружен в память) и OID (если он сохранен в БД)
(тоже относится и к сущности). OREF и OID являются уникальными, в глобальном смысле, ссылками на объект, и не являются его свойством. Объект с конкретным OID можно отобразить в памяти более одного раза – результатом будет множество объектов с одинаковыми значениями свойств, но система присвоит им различные OREF. Порожденные таким образом объекты можно сохранить в БД, тогда каждый из них получит уникальный OID. Если OREF и OID не приписывать к свойствам, то объекты Cache принадлежат мультимножеству. Заметим, что во многих практических реализациях РСУБД допускается нарушение свойства уникальности кортежей, правда только, для промежуточных отношений, порождаемых неявно при выполнении запросов.Как видно, основные структурные понятия реляционной модели данных можно свести к постобъектному подходу, следовательно в самом постобъектном подходе можно применять реляционное исчисление и исчисление предикатов.
Рассмотрим некоторые вопросы применения постобъектного подхода в реализации самоструктурирующихся БД. Прежде всего интересен вопрос: могут ли самоструктурирующиеся БД претендовать на уровень интеллектуальных ?
Самоструктурирующаяся БД состоит, в общем случае, из четырех связанных между собой блоков, каждый из которых представляет собой самостоятельную логическую структуру данных:
Самоструктурирующиеся БД, для своей реструктуризации в соответствии с поступающей информацией, используют язык формального описания отношений понятий, реализуемый в идеологии постобъектного подхода, но уровень формального описания не позволяет выявить некоторые контекстные потоки из поступающих данных, поэтому БД этого типа можно причислить лишь к разряду интеллектуализированных.
Постобъектный подход представления знания, отличающийся своей наглядностью, реально является альтернативой предикатного представления знания, т.к. класс может выступать как в роли понятия, так и в роли отношения между
понятиями.| Site of Information
Technologies Designed by inftech@webservis.ru. |
|